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(54) PROCEDE DE GENERATION AUTOMATIQUE D'UN 
D' ADMINISTRATION DE RESSOURCES INFORMAT1QUES. 

(5^ Le precede de generation automatique d'un module 
(19) cfune base d'informations cf administration (MIB) d'une 
ressource informatique (11) representee par objets et in- 
duant une architecture d'objets distribues (CORBA) selon 
un langage donn6 (IDL), consiste k former un fichier (100) 
cf un fichier de description (101 ) et dun fichier (1 02) de clau- 
ses de generation automatique, une clause comprenant au 
moins un mot cte determinant un mode de generation et au 
moins une caracteristique sur laquelle porte un mot c!6, et a 
appiiquer le fichier (100) a des moyens de generation (52, 
54) pour obtenir le module. 



MODULE D'UNE BASE D'INFORMATIONS 





2793908 

Titr 

Precede de gyration d'un module d'une base dlnf rmatLns 
d'administration de ressources informatiques. 

Domaine technique. 

L'invention concerne l'administration d'au moins une ressource 
infonnatique representee dans une technologie orientee objets. La ressource 
informatique peut etre un systeme infonnatique et/ou un r^seau infonnatique 
et/ou une application informatique. Llnvention a pour objet un precede de 
generation automatique d'un module d'une base deformations 
d'administration d'un tel systeme. La generation d'un tel module impliquant 
la modification des agents d'administration utilisant ladite base et d'un 
integrateur de ces agents, Invention s'applique aussi k la generation 
automatique d'un tel integrateur d'agents d'administration. 

L*invention est plus particulierement adaptee k un systeme 
informatique incluant une architecture d'objets distribu6s, telle que 
l'architecture CORBA (Common Object Request Broker Architecture) definie 
par le groupement de fournisseurs et d'utilisateurs travaillant a la 
normalisation de la gestion des objets et connu sous le nom OMG (Object 
Management Group) et l'architecture OLE/COM (Object Linking and 
Embedding / Component Object Modeler) de Microsoft. L'architecture CORBA 
sera prise comme exemple non limitatif dans la suite du texte. Dans le 
domaine de l'informatique distribuee, l'architecture CORBA permet de 
decrire des interfaces de services informatiques independamment des 
fournisseurs et des lan gages mettant en ceuvre ces services. La description 
des interfaces est faite k 1'aide d'un langage neutre de description dtaterface 
connu sous le nom de langage IDL (Interface Definition Language) defini 
aussi par le groupement OMG. Ce langage definit les frontteres d'un 
composant que constitue un objet g6re, c'est-i-dire les interfaces 
contractuelles du composant avec des clients potentiels. 
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L'invention a aussi pour objets corollaires le systeme 
d'administration et le systeme infonnatique qui mettent en ceuvre le precede. 

L'art ant6rieur. 

5 L'administration de ressources infonnatiques est ordinairement 

faite par une plate-forme logicielle d'administration dont on connait plusieurs 
types. La plate-forme qui servira d'exemple par la suite est celle connue sous 
le nom de marque d6pos£e OpenMaster, commercialism par le demandeur. 
Cette plate-forme se fonde sur une technologie & objets. Selon cette 

10 technologie, les moyens constituant la ressource informatique sont convertis 
en classes d'objets organises hierarchiquement dans une base deformations 
d'administration MIB (Management Information Base). Llnvention 
s'applique k la g6n£ration d'une partie, nominee module, de cette base. 

D'autre part, la plate-forme servant d'exemple utilise le protocole 

15 normalise de communication dedie k l'administration connu sous le nom de 
protocole CMIP (Common Management Information Protocol). Le protocole 
CMIP repose sur la norme ISO definissant les services pour le transfert des 
informations d'administration appeles services CMIS (Common Management 
Information Services). Ce protocole est organist selon un lan gage de 

20 description des informations d'administration appele langage GDMO/ASN.l - 
issu de directives pour la definition d'objets ger6s (Guidelines for the 
Definition of Managed Objects) selon le modele dHnterconnexion connu sous 
le nom de marque depos£e OSI (Open Systems Interconnection) de 
I'organisme international de normalisation ISO (International Standards 

25 Organisation), et de syntaxe ASNl (Application Syntax Notation One). Pour 
des raisons de commodite, ce langage sera appele simplement GDMO. 

Un probleme se pose quand l'administration de ressources 
infonnatiques au moyen de cette plate-forme utilise une architecture d'objets 
distribu6s telle que CORBA. Cette administration concerne non seulement 

30 Varchitecture CORBA elle-meme, mais aussi les services ^applications 
coop6rant avec cette architecture. Ces services peuvent etre administres par 
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llntermediaire d'une interface d'administration publi6e, decrite dans le 
langage IDL de l'architecture CORBA. A partir d'une description en lan gage 
IDL d'une interface d'un service CORBA, un compilateur IDL g6ndre dans un 
lan gage de programmation, par exemple C++, du code dont une partie, 
5 connue sous le nom normalise "skeleton", permet de mettre en oeuvre le 
service et dont une autre partie, connue sous le nom normalise "stub", permet 
d'appeler le service k partir d'un autre programme sous forme de 
biblioth&que. L'agent mis en ceuvre comme service particulier de CORBA a 
done une interface decrite en langage IDL. Cette description est aussi la 

10 description de l*information d'administration ofiferte par l'agent. Le langage 
IDL sert ainsi a la fois de langage de description dHnterface et de langage de 
description d'information d'administration. 

Le proc6de de generation automatique d'un module d'une base 
d'informations d'administration d'une ressource informatique representee par 

15 objets et incluant une architecture d'objets distribues CORBA selon le 
langage IDL, consiste actuellement k faire un fichier de description 
d'interface dans le langage IDL, k faire une conversion automatique du 
fichier et k compiler le fichier de description pour obtenir le module. 

Plusieurs algorithmes de conversion sont connus, tels que ceux 

20 publies par le groupe JTDM (Joint Inter-Domain Management) du groupe 
ORG. Cependant, ces algorithmes ne suffisent actuellement pas pour obtenir 
une version complete et exploitable en langage GDMO d'un module de la base 
MIB. Le probl&me est que des notions conceptuelles pouvant etre decrites en 
langage GDMO ne peuvent pas l'etre en langage IDL. Par consequent, on 

25 n'obtient qu'une partie settlement du module desire de la base MIB. 

La solution actuelle consiste a completer manuellement le code 
g6n£r6 par la conversion, de fagon k utiliser au mieux les caract&ristiques du 
langage GDMO. Cette solution a done comme premier inconvenient d'etre 
couteuse en temps et en argent. De plus, ce travail manuel doit etre reproduit 

30 apres chaque traduction dans le cas de changements du contenu du fichier de 
la description rendu disponible par un agent CORBA. C'est done une solution 
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ponctuell , qui doit etre revue et completee pour etre adaptee a chaque cas et 
qui a pour second inconvenient d'etre limitee au cas d'espdce et d'etre 
d'autant plus couteuse qull y a de changements de la description. Or, 
revolution de cette technologie est rapide et s'avdre done tr£s couteuse. Le 

5 troisieme inconvenient est du au fait que le fichier de description en langage 
IDL est traite par un compilateur, qui oblige la modification de la syntaxe du 
lan gage IDL. La syntaxe est ainsi alteree dans le seul but de la faire passer 
dans un generateur exterieur & l'architecture CORBA. 

La generation d'un module de base NUB implique directement la 

10 modification des agents d'administration qui servent de liens entre 
l'architecture CORBA et la plate-forme d'administration, ainsi que le 
composant servant d'interface entre ces agents et la plate-forme et appele 
integrateur d'agents. Le raeme fichier de description IDL est utilise pour 
modifier les agents et Hntegrateur de ces agents. Alors que la modification 

15 des agents ne pose pas de probl&me, la modification de llntegrateur d'agents 
CORBA pose le meme probleme que celui expose pr6cedemment. 

Sommaire de Tinvention. 

Un premier but de Invention est de g6n6rer automatiquement 
20 dans une base dlnformations d'administration MIB un module plus complet 

que celui fourni par la conversion automatique actuellement disponible, le 

module desire 6tant suffisamment complet pour etre exploitable pour 

Tadministration. Le module genere peut etre nouveau ou r6sulter d'une 

modification d*un module anteheur. 
25 Un second but est de g6nerer un module de base MIB exploitable 

sans alterer le fichier de description IDL. 

Un troisieme but est de g6nerer un module de base MIB 

exploitable et facilement adaptable aux changements de la description 

initiate. 

30 Un quatridme but est de generer simplement et k moindre cout 

un module de base MIB exploitable. 
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Un dnquieme but de llnvention est, comme consequence de la 
generation du module d'administration, de modifier automatiquement 
Pintegrateur d'a gents d'adininistration sans intervention manuelle. 

Llnvention a pour objet un procede de generation automatique 

5 d'un module d'une base d'informations d'administration (NUB) d'une 
ressource informatique representee par objets et incluant une architecture 
d'objets distribues (CORBA) selon un langage donne (IDL), consistant & faire 
un fichier de description d'interface dans le langage donn6 et a appliquer 
ledit fichier a des moyens de generation automatique pour obtenir une partie 

io dudit module, caracteris6 en ce qull consiste k ajouter audit fichier de 
description un fichier de clauses de generation automatique, une clause 
comprenant au moins un mot cle determinant un mode de generation et au 
moins une caracteristique sur laquelle porte un mot cle, et h appliquer le 
fichier de clauses auxdits moyens de generation pour completer ledit module. 

15 Accessoirement, le fichier de clauses et le fichier de description 

ne forment qu*un seul fichier, l*un des deux fichiers etant distingue de l'autre 
par une marque. 

De meme, les moyens de generation comprennent en outre un 
generateur (54) pour la generation automatique d'une partie d'un integrateur 

20 d'agents d'administration. 

Llnvention a aussi pour objet un ysteme d'administration d'une 
ressource informatique representee par objets definis dans une base 
d'informations d'administration (NOB) incluant un module, la ressource 
informatique incluant une architecture d'objets distribute (CORBA) selon un 

25 langage donne (IDL), caracterise en ce qu*il met en oeuvre ledit procede. 

Presentation des dessins. 

- La figure 1 est une vue synoptique d'un syst&me 
d'administration d'un systeme informatique, le systeme d'administration 
30 mettant en oeuvre un procede de generation automatique d'un module d'une 
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base MIB et du proced6 en resultant pour la generation automatique d'un 
integrateur d'agents d'administration. 

- La figure 2 est une vue synoptique detaillee de la structure 
d*une plate-forme d'administration du systeme d'administration repr6sente 

5 sur la figure 1. 

- La figure 3 est une vue schematique d'un arbre repr6sentatif 
d'un exemple de base MIB correspondant au systeme informatique repr^sente 
sur la figure 1 et incorporant le module a gen6rer conform^ment & Invention. 

- La figure 4 est une vue schematique d'une architecture d'objets 
10 distribues CORBA en liaison avec un integrateur d'agents CORBA de la 

plate-forme representee sur la figure 2. 

. Et la figure 5 est un organi gramme illustrant schematiquement 
le precede de generation automatique d'un module de base MIB, ce proc£de 
etant aussi utilise pour la generation automatique de l*int6grateur d'agents 
15 CORBA represents sur la figure 4. 

Description detaillee d'exemples illustrant l'invention. 

La figure 1 represente un systeme d'administration 10 d'un 
systdme informatique 11. L'exemple qui suit se rapporte au systeme* 

20 d'administration et de securite connu sous le nom de marque deposee 
OpenMaster du demandeur. Sa conception est conforme aux normes ISO de 
l'administration de systemes et reseaux. Dans ces conditions, les termes 
utilises seront conformes & cette nonne, qui sont de langue anglaise, 
notamment les sigles et acronymes. D'autre part, les verbes "administrer" et 

25 "gerer" et leurs derives qui seront employes id traduisent tous deux 
indifferemment le verbe anglais "manage" et ses derives. L'homme du metier 
connait bien ces normes. Compte tenu de leur masse informative, on ne 
donnera ici que les elements necessaires a la comprehension de invention. 

Le systeme informatique illustre 1 1 est distribue et compose de 

30 machines 12 (12a, 12b) organisees en un ou plusieurs reseaux 13. Une 
machine est une unite conceptuelle tris large, de nature materielle et 
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logicielle, pouvant etre les moyens impliques pour executor une application 
donnee, des moyens pour executor une fraction donnee, un ordinateur, ainsi 
qu'un systome infonnatique dans une architecture a systemes en cascade. Les 
machines 12 peuvent etre done tres diverses, telles que stations de travail, 
serveurs, routeurs, machines spedalisees et passerelles entre reseaux. Le 
systome infonnatique 11 est ordinairement un systome comp re riant plusieurs 
processeurs 14, un processeur 14 etant par exemple illustre dans chaque 
machine 12, des moyens de memoire 15 pour contenir les logiciels et les 
donnees du systome, et des moyens d'entree-sortie 16 servant pour la 
communication entre machines par l'mtermediaire du reseau 13 a l'aide de 
protocoles clivers, ainsi que pour une ou plusieurs communications 
extorieures, par exemple pour llmpression, la tolecopie, etc. Un tel systome 
peut par exemple gerer des donnees a distance, distribuer des donnees dans 
le cas d'un systome de reservation, commander l'execution de programmes k 
distance sur des machines specialisees, partager localement des ressources 
physiques ou logicielles, et communiquer. 

Le systome d'administration 10 a une architecture de type client- 
serveur. Dans l'exemple illustre, les unites form ant clients et serveurs dans le 
systome d'administration 10 comprennent deux gestionnaires 17a formant 
serveurs et trois agents 17b formant clients. Une machine 12 induant un 
gestionnaire est dite machine gestionnaire ou serveur 12a et une machine 
induant un agent est dite machine geree 12b ou diente. Les gestionnaires 
17a et les agents 17b sont relies entre eux par l'intormediaire du reseau 13. 
Dans l'exemple illustre, les deux gestionnaires sont relies entre eux, l'un des 
gestionnaires 17a etant relie a deux des agents 17b tandis que l'autre est 
relie aux trois agents. Les liaisons entre gestionnaires et agents peuvent etre 
tres diverses. D'autre part, les communications entre gestionnaires et agents 
peuvent se faire selon un ou plusieurs protocoles, de preference normalises 
tels que les protocoles CMIP (deja dte) et SNMP (System Network 
Management Protocol). Le protocole CMIP repose sur la nonne ISO 
definissant les services pour le transfert des informations d'administration 
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appeles services CMIS (Common Management Information Services). Chaque 
protocole est organise selon un langage de description des informations 
^administration. Par exemple, le protocole SNMP utilise le langage SMI 
(Structure of Management Information) tandis que le protocole CMIP utilise 

5 le langage GDMO/ASN.l dejk cite, et simplement appele GDMO. 

La figure 2 illustre la structure d\me plate-forme 
d'administration 20 du systeme d'administration 10. La plate-forme 20 peut 
etre limine k une machine gestionnaire 12a, ou etre distribute parmi 
plusieurs machines gestionnaires. Pour des raisons de commodite, la plate- 

10 forme illustree dans la figure 2 sera limitee 4 une machine gestionnaire 12a 
et correspond ainsi au gestionnaire 17a. La plate-forme illustree 20 se 
compose de cinq blocs fonctionnels : un bloc 30 ^applications en langage SML 
(Systems Management Language), un bloc 40 de services, un bloc 50 
dintegrateurs d'agents, un bloc 60 d'interface de gestionnaire, et un bloc de 

15 communication 70. 

Le bloc 30 ^applications inclut un ensemble ^applications de . 
base 31 (core applications), une interface graphique d'utilisateur 32 appelee 
interface GUI (Graphic User Interface), un tableau de bord constituant un, 
lanceur ^applications 33, une interface 34 de communication exterieure du 

20 bloc 30, et un ensemble 35 de fonctions de haut niveau. Dans 1'exemple choisi, 
les applications 31 sont 6crites dans le langage SML et communiquent avec le 
bloc 70, utilisant le protocole CMIP et le langage GDMO, par ^interface 34 
qui est done ici une interface SML/GDMO. LHnterface GUI 32 permet a un 
utilisateur de se connecter k la machine 12a pour d&narrer et arreter comme 

25 il le desire ses propres copies des applications de base 31. Le lanceur 
duplications 33 presente un tableau representant les applications 31 sous 
forme generale par leur nom et/ou, comme dans Texemple choisi, sous forme 
d'icones. D suffit de cliquer sur Hcdne choisie pour lancer Implication 
correspondante. Les fonctions de haut niveau 35 sont ajout£es pour ofErir des 

30 fonctions particulidres et des interfaces graphiques correspondantes. 
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Le bloc 40 comprend plusieurs services, notamment un service 
41 de base de donnees CMIS, appele service CMIS-DB, un service 42 de 
schemas dinformations d'administration ou service MISS (Management 
Information Schema Service), un service 43 de journal d'alarmes et un service 

5 44 de journal d'evenements normalement connecte a un journal d'evenements 
non illustr6. Le bloc 50 illustre contient seulement un integrateur 51 d'agents 
d* administration, appele ordinairement par le sigle AI (Agent Integrator) et 
affecte a un protocole particulier, id le protocole CORBA, d'autres 
integrateurs d'agents pouvant exister pour le protocole SNMP, etc le 

10 protocole CMIP est utilise comme exemple dans la plate-forme 20. 
L/integrateur 51 d'agents est connecte au bloc 70 et a un ou plusieurs agents 
17b fonctionnant sous le protocole correspondant, ici CORBA. Dans l'exemple 
illustre, le bloc 50 inclut aussi des moyens de g6n6ration 52, 53 et 54 et des 
moyens de compilation 55 qui, d'une manidre g6n6rale, pourraient etre 

15 contenus dans une partie quelconque de la plate-forme 20. Le bloc d*interface 
60 permet a la plate-forme 20 de communiquer avec un autre gestionnaire 
17a du systeme 10, pouvant etre un supragestionnaire de niveau 
hierarchique sup^rieur. Enfin, le bloc de communication 70 constitue un lien 
entre les autres blocs et est appele courtier de requetes CMIS ou distributeur 

20 CMIS (CMIS Dispatcher). II contient un routeur 71 d'evenements, permettant 
aux composants d'administration de souscrire k des notifications 
d*6v6nement, un routeur 72 de commandes pour transmettre des requetes au 
composant destinataire et eviter aux applications de savoir quel composant 
"possede" chaque instance MOI, une infrastructure de s^curite 73, un 

25 gestionnaire 74 d'objets sous la racine ROOT (ROOT Object Manager), et une 
horloge 75 (timer). 

Selon une option courante et avantageuse du systdme 
d'administration 10, un gestionnaire 17a gere aussi la machine gestionnaire 
12a correspondante ou gere tout ou partie des machines gestionnaires. Cela 

30 peut se faire de fagon similaire a celle illustree precedemment, plus ou moins 
adaptee k cette option. L'exemple illustre ffire le double avantage de faciliter 
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la lecture des dessins tout en permettant a 1'homme du metier de faire une 
generalisation du systeme decrit et illustre. 

Le systeme informatique 11 de la figure 1 se compose de moyens 
materiels ou logiciels, r6els ou virtuels, tels que machines, imp rim antes, 

5 circuits virtuels et applications. Le systeme d'administration 10 utilise ces 
moyens selon un modele de donnees oriente objets, dont on connait les 
principales caracteristiques : classes, objets, heritage, encapsulation, 
methodes (ici actions) et evenements. I/organisation des classes dans 
l'exemple choisi du systeme 10 est hierarchique. On distingue : l'arbre des 

10 classes, une classe etant definie en subordination k une ou plusieurs classes 
mdres ; et l'arbre des instances, une instance etant attachee & une ou 
plusieurs instances mdres. En particulier, une classe est definie par des 
caracteristiques nominees attributs, tels qu'un nom d'un compos ant du 
systeme et un etat d*impression. Un objet d'une classe sera appele une 

15 instance de la classe. Dans Pexemple choisi, les moyens du systeme 
informatique 11 sont done convertis en classes d'objets organis&s 
hi6rarchiquement dans une base d'informations d'administration MIB 
(Management Information Base). Cette base n'est pas une base de donnees 
proprement dite, mais est assimilable a un catalogue de caracteristiques 

20 puisqu'elle contient la description et le contenu de toutes les classes ger6es 
par le systeme d'administration 10. Dans la base MIB, les objets sont divises 
en classes d'objets geres, dites classes MOC (Managed Object Class). Un objet 
gere est une vue abstraite, definie pour les besoins de la gestion, d'une 
ressource logique ou physique d'un systeme. Chaque classe MOC represente 

25 un type donne desdits moyens du systeme 1 1. A chaque classe MOC peuvent 
etre attachees une ou plusieurs instances d'objets g^s, appelees instances 
MOI (Managed Object Instance) et representant des occurrences actuelles 
desdits moyens. 

La figure 3 illustre un exemple de structure d'une base MIB. Elle 
30 a une structure arborescente, faite d'une racine ROOT a laquelle sont 
attaches des sous-arbres ou sous-MIB 18, ici representatifs des trois machines 
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gerees 12b appelees Mac-a, Mac-b et Mac-c. Les sous-arbres 18 sont aussi 
representes sous forme syuoptique dans la figure 1, en liaison avec les agents 
17b respectifs. La racine ROOT est contenue dans le gestionnaire 74 et les 
rarines des sous-arbres seront appelees sous-racines correspondant au terme 
5 anglais Rootlet. Ainsi, toute application 31 devant traiter un objet de la base 
MIB s 9 adresse au gestionnaire 74 pour acceder & l'objet Dans 1'exemple 
illustre, on a suppose que chaque machine 12b a, comme reprSsente sur la 
figure 1. trois cartes 19, 4 savoir une carte-r6seau R, une carte vid6o V et une 
carte-son A, de sorte que chaque sous-arbre 18 correspondant contient les 

10 trois objets correspondants. Dans la figure 3, seul le sous-arbre 18 relatif & la 
machine Mac-b a ete developpe. On y voit que le sous-arbre 18 a la sous- 
racine Mac-b incluant trois fils constitues par les trois objets respectifs carte- 
reseau, carte video et carte-son (R, V et A). Llnvention s'applique k la 
g6n6ration automatique d'une partie de 1'arbre, appelee module 

15 deformations d'administration 19 et faite d'au moins un objet g6re MOC et 
dont la description en langage IDL est issue d'un agent CORBA 51. Le 
module est d6fini de fa^on abstraite par un trait fan tome dans la figure 3. 
L'invention a pour objet un precede de generation automatique d'un module 
19 k partir d'un fichier de description en langage IDL, ce precede etant mis en 

20 ceuvre dans un in tegrateur d'agent 5 1 . 

Une instance dans la base MIB a un nom distinctif relatif RDN 
(Relative Distinguished Name) sous forme d'une liste d'assertions sur valeur 
d'attribut appelees assertions AVA (Attribute Value Assertion). Chaque 
assertion AVA est un couple <attribut de nommage> <valeur>, 1'attribut de 

25 nommage etant celui qui, dans la classe, permet identification unique d'une 
instance par rapport 4 son instance mere. Dans un gestionnaire 17a de 
l'exemple illustr£, un nom RDN est compose d'une seule assertion AVA, done 
d'un seul couple <attribut de nommage> <valeur> D'une manidre g£n£rale, il 
est cependant possible qu'un nom distinctif RDN ait plusieurs assertions 

30 AVA. Chaque instance dans la base MIB est identifiee de fa$on unique par 
son nom distinctif DN (Distinguished Name), qui est la suite des noms RDN 
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sur le chemin entre la racine et l'instance dans l'arbre des instances. Un sous- 
arbre d'une instance correspond a l'ensemble form6 par l'instance elle-meme 
et les instances qui lui sont subordonn£es dans l'arbre des instances. 

Sous la racine ROOT de la base MIB est attachee une sous- 

5 racine pour chaque service du bloc 40. Dans ce bloc, le service CMIS-DB 41 
fournit une base de donn6es des objets geres MOI destin6e a leur persistence 
une fois que le gestionnaire a et6 mis hors fonctionnement. II supporte toutes 
les classes MOC des services CMIS qui sont stockees localement dans une 
base de donnSes. En outre, il fournit un ensemble de services ou fonctions de 

10 base, appelees aussi primitives, disponibles pour toutes les applications, Ces 
fonctions sont bien adaptees a la structure hierarchique de la base MIB. EDes 
incluent notamment les fonctions : M-GET pour lire une ou plusieurs 
instances, M-SET pour mettre a jour une ou plusieurs instances, M-CREATE 
pour creer une instance, M-ACTION pour activer une operation sp&afique 

15 sur une ou plusieurs instances et M-EVENT pour envoyer un 6v6nement. Ces 
fonctions supportent les notions de filtrage offrant la possibility de filtrer les 
instances selon certains criteres portant sur leurs attributs et les notions de 
port£e (scope) permettant de preciser le niveau de profondeur dans l'arbre des. 
instances. 

20 Le service MISS 42 fournit les moyens d*identification des objets 

g6r£s, les moyens etant ceux definis initialement dans les documents de 
definitions GDMO contenus dans une description GDMO. D pennet 
d'ex^cuter des processus de description pour entrer un nouveau jeu de 
definitions en utilisant un compilateur GDMO et des processus de recherche 

25 (retrieval processes) pour savoir comment une information d f administration 
anterieurement entree peut etre lue par n'importe quel composant de la 
plate-forme 20. Ces deux processus partagent une base de donn£es appel6e 
base de schemas dHnformations d'administration, souvent abregee en base de 
schemas ou base MISB (Management Information Schema Base). EUe sert au 

30 stockage de tous les jeux correctement compiles des definitions dinformations 
d'administration. La base est modelisee par une base MIB. Cela signifie que 
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la structure de 1'information contenue dans la base de schlmas est 
logiquement vue comme une base NUB et qu'elle utilise elle-meme la notation 
GDMO. Cette vue logique de la base de sch6mas est une partie de la base 
NUB globale accedee par la plate-forme 20 et est appelee base MIB de 

5 schemas d 'informations d'administration. 

Les m£canismes et modalites d'echange entre objets peuvent etre 
regis de diverses fagons dans les machines. Parmi elle, 1'exemple choisi utilise 
les mecanismes et modalites regis par une architecture d'objets distribute, 
Farchitecture CORBA en l'occurrence. Dans le domaine de rinformatique 

10 distribute, ^architecture CORBA permet de specifier des interfaces de 
services informatiques independamment des fournisseurs et des langages 
mettant en oeuvre ces services. La specification des interfaces est faite a l'aide 
d'un lan gage neutre de description d' interface connu sous le nom de langage 
IDL (Interface Definition Language) defini aussi par le groupement OMG. Ce 

15 langage definit les frontieres d'un composant que const! tue un objet ger6, 
c'est-a-dire les interfaces contractuelles du composant avec des clients 
potentials. 

On a vu que l'integrateur 51 d'agents sert d'interfaces entre la 
plate-forme 20 et les agents correspondants 17b de r architecture CORBA. 

20 La figure 4 illustre la structure d'une architecture CORBA 90 en 

liaison avec la plate-forme 20 par Pintermediaire de l'integrateur d*agent 51 
de type CMIP/CORBA. L f architecture CORBA 90 comprend : un courtier 91 
de requetes d'objets ou courtier ORB (Object Request Broker) definissant un 
bus des objets CORBA ; un ensemble 92 de services CORBA definissant les 

25 infrastructures d'objets au niveau systeme qui etendent le bus ; un ensemble 
93 ^applications CORBA ; un ensemble 94 d'instaUations CORBA (CORBA 
facilities) definissant les infrastructures horizontales et verticales qui sont 
utilisees directement par les objets d'affaire (business objects) ; et un 
compilateur IDL 95. 

30 Comme il a ete dit en introduction, le proced6 connu de 

generation d'un module de base MIB consiste & utiliser un fichier de 
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description IDL tel quindique dans Tannexe IB a la presente demande, qui 
fait partie de la description et a appliquer le fichier & un g6n6rateur 52 pour 
obtenir une partie dudit module, 

Pour la realisation du gen6rateur 52, on connait plusieurs 

5 algorithmes de conversion, notamment les algorithmes d'administration 
inter-domaine et connus sous le nom JIDM (Joint-Inter-Domain 
Management) issus du groupement OMG. Cependant, ils ne suffisent pas 
pour obtenir une version complete et exploitable en langage GDMO. Cette 
insuffisance est due au fait que des notions conceptuelles pouvant etre 

10 decrites en langage GDMO ne peuvent pas Tetre en langage IDL. Ces notions 
sont notamment : 

- la definition des attributs de nommage, 

- des regies de construction d'arbres connus sous le nom de liens 
de nommage et plus ordinairement name-binding, 

15 - Tallocation d'identifieurs d'objets, et 

- Tutilisation d'une meme description d'attribut dans des 
interfaces diflerentes. 

La solution k ce probleme consiste & ajouter au fichier de 
description IDL de Tannexe IB des commentaires pour la conversion, tels que 

20 ceux illustres dans Tannexe 1A Selon Texemple de Tannexe 1, les 
commentaires de Tannexe 1A sont contenus dans une zone de commentaires 
solidaire du fichier de description IDL de Tannexe IB, la zone de 
commentaires pouvant pr&6der ou suivre la description IDL. Dans ce cas, la 
zone se distingue des autres commentaires de la description IDL (annexe IB) 

25 par une marque, en Toccurrence la marque GEN. Selon une van ante possible, 
les commentaires de Tannexe 1A pourraient etre contenus dans un fichier 
similaire a la zone illustree mais independant du fichier de description IDL. 
Dans ce cas, il suffit d'appeler le fichier de commentaires pour completer la 
description IDL. Ainsi, la description IDL peut toujours etre passle au 

30 travers du compilateur IDL 95, avec les memes r6sultats, puisque la s)naitaxe 
du langage n'est pas modifi^e. 



2793908 



-15- 

La figure 5 illustre schematiquement le precede. Le bloc 100 
comprend le fichier constitue du fichier de description IDL 101 illustre dans 
I'annexe 1A et la zone de commentaires 102 illustre dans I'annexe IB. Le 
fichier 100 est applique k Tentree du premier generateur 52 pour generer le 

5 module 19 de base MIB. Le module 19 est done un fichier de description en 
lan gage GDMO. Le module 19 est ensuite int6gr6 dans la base MIB. En 
pratique, dans 1'exemple illustre, Integration du module 19 dans la base 
MIB est faite par compilation du module 19. La compilation est faite id par le 
compilateur GDMO 55 illustre dans la figure 2. Le module 19 est directement 

10 assimilable par le compilateur 55. Le compilateur 55 a pour nom gdmoc dans 
le produit OpenMaster de 1'exemple considere. n prend la description GDMO 
du module 19 en entree, en verifie la syntaxe et entre cette description dans 
la base MISS 42 de la figure 2 pour rendre disponible la description aux 
services 40 et aux applications 31 de la plate-forme 20. 

15 La figure 5 illustre aussi un proc6d6 en resultant pour la 

generation automatique de Pintegrateur 51. Cet int£grateur tel qu'illustrt 
sert a la conversion du langage IDL en protocole CMEP. Un agent integrateur 
CORBA 17b de la figure 2 est forme selon la technique anterieure, qui 
consiste k appliquer le fichier de description IDL 101 de 1'annexe IB k l'entrte 

20 du compilateur IDL 95. Une premiere partie 51a de VintSgrateur 51 est faite 
aussi a partir du compilateur 95. En fait, le compilateur 95 fournit une partie 
dite "skeleton" k l'agent CORBA et une partie dite "stub" k l*int£grateur 51 
pour en constituer la premiere partie 51a. Une seconde partie 51b de 
rint£grateur 51 est aussi faite selon la technique anterieure, qui consiste k 

25 appliquer le module 19 de description GDMO au second generateur 53, 
adapte k la g6n6rattion automatique d'integrateur d'agent k partir d'une 
description GDMO, cet outil etant appele OPAL/ADK dans le produit 
OpenMaster®. A noter toutefois que dans la technique anterieure, le module 
GDMO etait celui complete manuellement alors que dans Invention, il est 

30 g6ner6 en entier automatiquement. Selon Invention, une troisi&me partie 
55c de llnt^grateur 51 est faite simplement et automatiquement a partir du 
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fichier 100 au moyen du troisieme generateur 54. Le generateur 54 convertit 
le langage IDL du fichier 100 en un langage, par exemple C et/ou C++ qui 
sert a faire un lien entre la partie 56a gener^e k partir du langage IDL et la 
parti e 56b generee a partir du langage GDMO. 

5 Les commentaires illustr6s en annexe 1A sont donnas a titre 

indicatif et vont maintenant etre commentes. On a vu que la marque GEN est 
ajoutee au debut d'un commentaire pour etre interpretee par les g£n6rateurs 
52 et 54 comme debut de commentaire. Les commentaires se composent de 
clauses ay ant chacune leur signification pour le g6n6rateur 52. Une clause se 

10 compose d'au moins un mot de s'appliquant k au moins un attribut qui le 
suit. Les clauses illustrees en annexe sont classees en plusieurs types qui ont 
ete numerates par les lettres A-E en italique et entre parentheses dans le seul 
but de faciliter leur presentation. Cette presentation est faite aussi en 
reference k l'annexe 2 k la prdsente description et en en faisant partie. 

15 L'annexe 2 donne simplement une liste explicative des types des clauses, 
utilisees, id A-H. 

Dans l'annexe 1A, la dause de type A se compose du mot de 
METHOD_TO ^ATTRIBUTE suivi d*une methode, id getjabel, et d'un 
attribute id label. Selon l'annexe 2, cette clause indique aux g6n6rateurs 52 et 

20 54 de convertir la methode getjabel en I'attribut label. On notera que le. 
convertisseur 52 de services CMIS ne generera aucun service M- ACTION 
mais que les generateur 52 genereront I'attribut specifie. En d'autres termes, 
un dause du type (A) comprend un mot de (METHOD_TO_ATTRIBUTE), 
une premiere caracteristique representative du nom d*une methode et une 

25 seconde caracteristique representative d'un attribut, le mot de indiquant au 
generateur de convertir ladite methode en ledit attribut. 

Dans l'annexe 1A, la dause de type B a le mot de 
MULTIPLE JDECLARE, qui signifie aux generateurs 52 et 54 qu'ils vont 
trouver une premiere interface induant l'attribut qui le suit, id "hostname" 

30 et une seconde interface induant aussi cet attribut. II est k noter qu'en 
langage GDMO il est possible d'utiliser la meme definition d'attribut dans des 
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classes differentes d'objets geres (classes MOC). Ainsi, quand les g£n6rateurs 
trouvent la premiere interface, ils g£ndrent une premiere classe MOC a partir 
de cette premiere interface et, de meme, quand les g6n6rateurs trouvent la 
seconde interface, ils generent une seconde classe MOC & partir de cette 
seconde interface. lis utilisent done le meme attribute ici "hostname" dans le 
langage GDMO. En bref, clause du second type B comprend un mot de 
(MULTIPLE_DECLARE) et un attribut, le mot de indiquant au g6n£rateur 
de generer des classes d'objets a partir dudit attribut. 

Dans les commentaires de l'annexe 1A, la clause de type C a le 
mot de IGNORE, qui signifie aux generateur de ne pas traduire le terme IDL 
qui le suit. Le terme peut etre notamment un nom d*interface, un nom 
d'exception, un nom d'attribut et un nom de methode. Dans l'exemple illustr6, 
le terme est un attribut nomm6 "ActualAttributeValue_r. En d'autres termes, 
les generateurs ne modifient pas le langage IDL pour la conversion. Ce mot 
d6 offire 1'avantage de ne pas generer des choses inutiles dans la description 
GDMO, cela sans toucher au fichier de description IDL. 

La dause de type D a le mot de TYPEDEF, qui indique aux 
generateurs 52 et 54 qu'il faut remplacer le premier mot qui le suit, 
representatif d'un type du langage GDMO, id "InterfaceDef, par le second 
mot representatif d'un type du langage IDL, id "Object* f normalement defini 
par une partie code dans le fichier de description de l'annexe IB, cette partie 
de code commen^ant id par un terme nomm6 "indude" et reference par le 
caractere TP. Cette dause permet de faire des synonymes entre les deux 
langages correspondants. En fait, cette dause est un moyen de definir un 
type de donntes utilise en langage IDL a partir du type de base. Cette 
definition est normalement faite par le verbe "typedef du langage IDL et est 
importee dans le fichier de description k Paide des termes "indude". Cette 
dause s'explique par l*incapadte des generateurs de l'exemple illustre, pour 
des raisons de limitations imposees par la realisation de ces generateurs, de 
ch rcher les termes "indude" dans le fichier de description IDL. Comme la 
version courante des generateurs utilises dans l'exemple choisi ne gere pas 



2793908 



-18- 

les clauses de precompilation qui commencent par le caractdre dans le 
fichier de description IDL de Tannexe IB, il a ete ajoute au fichier de 1'annexe 
1A du code qui est present avec les termes "include- et n6cessaire k la 
conversion au debut du fichier de description de 1'annexe IB. En outre, dans 

5 le fichier de description de 1'annexe IB, il est ajoute une premiere marque 
suivi d'un terme non defini, id "Mfdef FORjGENERATORJTIME % et une 
seconde marque "#endif (non illustree). Ainsi, le compilateur 55 de la figure 
2 ignore ce qui est entre ces deux marques puisque le terme 
"FORJGENERATORJTIME " n'est pas defini. Dans le compilateur, le 

io pr6processeur (non illustre), qui gen&re du code C++ & partir du fichier de 
description, 6jecte la partie entre les deux marques alors que les deux 
generateurs 54 et 55 vont les prendre en corapte. En d'autres termes, on peut 
dire que si les generateurs 52 et 54 ne gdrent pas des clauses de 
precompilation, une clause de troisteme type (D) inclut un mot d6 

15 (TYPEDEF) et deux mots, le mot de indiquant aux generateurs 52 et 54 quil 
faut remplacer Tun (InterfaceDef) des deux mots, representatif d'un type 
dudit module, par l'autre mot (Object) representatif d'un type du langage 
donne IDL normalement defini par une partie de code (sous #indude) dans le 
fichier de description. 

20 Les dauses de type E dans les commentaires de l'annexe 1 A sont v 

relatives aux liens de nommage, appdes name-binding. Ces dauses sont dues 
au fait qu*il n'y a pas de liens de nommage entre dasses en langage IDL mais 
quil en existe en GDMO. Cette dause permet ainsi d'introduire des liens de 
nommage name-binding dans une definition. Les dauses de type E 

25 comprennent trois mots des SUPER, SUBORD et NAME, suivis 
respectivement de mots (caracteristiques d'objets, attributs, etc.). Le mots d£s 
SUPER et SUBORD designent respectivement les dasses superieures et 
subordonn^es d'objets et le mot de NAME designe 1'attribut de nommage de 
la dasse subordonnee. Par exemple, la dause "SUPER orb SUBORD 

30 AgentSystem NAME hostname" indique quHine instance de la dasse 
"AgentSystem" peut se trouver sous, ou etre c ntenue dans, un instance de 
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la classe •orb" et qu'elle est noraraee, en tant qu'attribut utilise pour le nom 
RDN, avec l'attribut "hostname** qui appartient a la classe w AgentSystem". En 
d'autres termes, une clause de quatrieme type (E) comprend trois mots cles 
(SUPER, SUBORD, NAME correspondant respectivement a trois 
5 caracteristiques (orb. AgentSystem, hostname), deux des mots cl6s design ant 
par leurs caracteristiques correspondantes deux instances de classes 
respectivement sup£rieure et inferieure et le troisieme mot cle design ant par 
la troisidme caract&ristique l'attribut de nommage de la classe subordonnee. 

Les clauses de types F et G de l'annexe 2 sont des clauses 

10 introductives. Ainsi, la clause de type G sert & nommer le module GDMO 
genere par le generateur 54 et la clause de type H sert & nommer le module 
ASN1 genere par le generateur 55. 

La clause de type H de l'annexe 2 necessity les observations 
prelimin aires suivantes. Tous les objets semantiques GDMO gen£r£s (MOC, 

15 NameBinding, Package, Attribute) sont identifies par des identifieurs d'objets 
(Object IDentifiers) tels que definis par la norme ASNl. Ces identifieurs sont 
des suites d'entiers reprenant un meme prefixe. Par exemple, si on alloue la 
suite "1 3 12" comme prefixe, on allouera automatiquement dans la 
generation automatique les identifieurs "1 3 12 1 P, "1 3 12 1 2", "1 3 

20 12 1 3", -1 3 12 1 4", ... pour identifier les classes MOC, puis les 
identifieurs "1 3 12 2 r,"l 3 12 2 2", "1 3 12 2 3", "1 3 12 2 4",... 
pour identifier les liens de nommage name-binding, etc La clause de type J 
permet de demander aux genera teurs 54 et 55 de prendre un prefixe different 
de ceux definis precedemment. Selon notre exemple, la clause "OIDJTAG 15" 

25 demandeau generateur de changer le prefixe precedent, id "1 3 12" en "1 3 
15".En fait, Jes identifieurs sont generes a l'aide du prefixe, qui est allou£ 
dans le systeme d'administration 10 pour le systdme COBA et auquel est 
ajoute un en tier supplementaire, le nombre 15 dans l'exemple illustrS. Cet 
entier supplementaire sert 4 distinguer des generations en langage IDL entre 

30 elles et, done, h distinguer entre eux des modules de base MIB differents. 
Ainsi, s"il existe plusieurs types d'agents implementant des modules 
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differents de base MIB, il est possible de voir tous ces agents dans la base 
MIB du systeme ^administration 10. En d'autres termes, si les objets sont 
identifies par des identifieurs (OID) ayant un meme prefixe, une clause de 
cinquteme type (H) comprend un mot de (OIDJTAG) et un entier (15), le mot 
cl6 indiquant au g£nerateur de prendre un prefixe different et defini par ledit 
entier. 
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ANNEXE 1A 



10 



15 



20 



25 



30 



(zone de commentaires) 



35 



//- 



//GEN: METHOD_TO_ ATTRIBUTE getjabcl label 

(A) 

II 

//GEN: MULTIPLE_DECLARE hostname 
//GEN: MULTIPLE DECLARE value 



//- 



//GEN: IGNORE ActualAtthbuteValuej 
//GEN: IGNORE AttributeRefetence I 



//- 



//GEN: TYPEDEF InlerfaoeDef Object 
//GEN: TYPEDEF eventjvpe_schemaj string 
//GEN: TYPEDEF AttributeDef Object 
//GEN: TYPEDEF OperationDef Object 



fly 



//- 



//name-bindings : 

(E> 

II 



SUBORD orb NAME orb_name 

SUBORD Gateway NAME gatewayjiame 



//GEN: SUPER top 
//GEN: SUPER orb 
// 

//GEN: SUPER orb SUBORD AgentSystem NAME hostname 

//GEN: SUPER OibtxSetver SUBORD OrbixORBCoreSegment NAME label 

//GEN: SUPER OrbixSctvcr SUBORD OrbixBOAScgmenl NAME label 

//GEN: SUPER OrbixServer SUBORD CORBAApplicalk>nOb^TypeCMO NAME label 



//GEN: SUPER OrbixORBCoreSegment SUBORD OrbixConnection 
//GEN: SUPER CORBAApplicationObjectTypeCMO SUBORD 
CX)RBAApr^katk)nObjectInstanceCMO NAME label 



//- 



NAME label 
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ANNEXE IB 



5 (Fichier de description 1DL) 

#include <oib.kiI> 
#indude<IRDfs.idl> 
#indude <OperDf kfl> 
10 findudc <InterDf.id> 
#indude "TimeJdl" 
tfndude "Naming. idT 
//cssai 

//findude "EvciuManagcment idl" 
15 #ifdef FOR_GENERATOR_TIME 

module TimeBase { 

struct uk>nglong{ 
20 unsigned long low, 
unsigned long high; 

}; 
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ANNEXE2 



10 



15 



20 



25 



30 



35 



CLAUSES DE GENERATION 
Usage : gdmo file.idl > file gdrao 

//GEN: GDMOJtfODULEJJAME jltAdm (F) 
Spdcifk le nom du module GDMO gtoM (par ddfaut : "oibAdm* 
Toutes les interfaces traduites sont dietaries en un seul module GDMO. 
Attention : cette clause doit etre plac6e devant toute instruction IDL. 

(Le g^ndrateur ne traduit pas les definitions de module IDL en definitions conespondantes en GDMO, 
mais cr6e seulement un module GDMO). 

//GEN: ASN1_M0DULE_NAME Idl2 (G) 

~> nom du module ASN1 genet* (par ddaut : "Idl") 

Attention : cette clause doit toe plac6e devant toute instruction IDL. 

//GEN: OIDJTAG 15 (W 

' La vakur pour le composant identifteur cfobjct OID associe * "corbe" 
Rennet <f avoir diiTdientes generations pour utiliser difl&ents kfcntifieurs OIDs ... 

//GEN: METHOD^TO. ATTRIBUTE get Jabel label (A) 

-> La mahode "getJabeT est traduite en Pattribut label* 

La syntaxc rctoun^e par la rndthode est utilisde comme type d'attribut. 

Aucune m-action est gtntortc pour la methode, seulement Faltribut spdcifid 

//GEN: MULTIPLE_DECLARE hostname (B) 
-> Quand un m&ne nom d'attribut est utilise dans difKrcntes interfaces IDL, ceci avertit le generateur de 
produire seulement one definition d'attribut GDMO. 



//GEN. IGNORE EvcntSchemaMetaDef 

-> Specific que r interface donnde n'a pas a etre traduite en GDMO. 
//GEN: TYPEDEF IntenaceDef Object 

-> Permet de definir un type qui est norma lenient defini avec le terme •include*. 



(C) 



(D) 
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//GEN: SUPER root SUBORB AgenlSystem Name hostname (E) 
-> lien de nommage name-binding i ggn&er 

Sp&ifie : classes (fobjets sup^rieures ct subordonndcs (ou noms d'intcrface qui sont & traduire en noms 

MOQl 

"root" peut etre spdciftt pour la classe MOC sous la racine de la MTB. 
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R vendications 

1. Precede de generation automatique d'un module (19) d'une 
base d'informations d'administration (MIB) d'une ressource informatique (11) 

5 representee par objets et incluant une architecture d'objets distribu£s 
(CORBA) selon un langage donne (IDL), consistant a faire un fichier 
(annexe IB) de description d'interfiace dans le langage donn6 et a appliquer 
ledit fichier a des moyens de generation automatique (52) pour obtenir une 
partie dudit module, caracterise en ce qu'il consiste a ajouter audit fichier de 

10 description un fichier (annexe 1A) de clauses de generation automatique, une 
clause comprenant au moins un mot cle determinant un mode de generation 
et au moins une caracteristique sur laquelle porte un mot cle, et a appliquer 
le fichier de clauses auxdits moyens de generation pour completer ledit 
module. 

15 2. Precede selon la revendication 1, caracterise en ce que le 

fichier de clauses et le fichier de description ne forment qu'un seul fichier 
(100), Tun (annexe LA) des deux fichiers etant distingue de l'autre par une 
marque (GEN). 

3. Precede selon la revendication 1 ou 2, caracterise en ce qu'une 
20 clause d'un premier type (A) comprend un mot cle 
(METHODJTO_ATTRIBUTE), une premiere caracteristique representative 
du nom d'une methode et une seconde caracteristique representative d'un 
attribut, le mot cle indiquant aux moyens de generation de convertir ladite 
methode en ledit attribut. 
25 4. Precede selon l'une des revendications 1 a 3, caracteris6 en ce 

qu'une clause d'un second type (B) comprend un mot cle 
(MULTIPLEJDECLARE) et un attribut, le mot cle indiquant au generateur 
de generer des classes d'objets a partir dudit attribut. 

5. Precede selon Tune des revendications 1 a 4, caracterise en ce 
30 qu'une clause de troisieme type (C) comprend un mot cle (IGNORE) et une 
caracteristique, le mot cle indiquant aux moyens de generation d'ignorer 
ladite caracteristique. 
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6. Procede selon Tune des revendications 1 a 5, caracterise en ce 
les moyens de generation ne gerant pas des clauses de precompilation, une 
clause de troisieme type (D) inclut un mot cle (TYPEDEF) et deux mots, le 
mot cle indiquant aux moyens de generation qu'il faut remplacer Tun des 

5 mots (InterfaceDef) par l'autre mot (Object) representatif d'un type du langage 
donne normalement defini par une partie de code (sous #include) dans le 
fichier de description. 

7. Procede selon Tune des revendications 1 a 6, caracterise en ce 
qu'une clause de quatri£me type (E) comprend trois mots cles (SUPER, 

10 SUBORD, NAME correspondant respectivement a trois caracteristiques (orb, 
AgentSystem, hostname), deux des mots cles designant par leurs 
caracteristiques correspondantes deux instances de classes respectivement 
superieure et inferieure et le troisieme mot cle designant par la troisieme 
caracteristique l'attribut de nommage de la classe subordonnee. 

15 8. Procede selon Tune des revendications 1 a 7, caracterise en ce , 

que les objets etant identifies par des identifieurs (OID) ayant un meme 
pre fixe, une clause de cinquieme type (H) comprend un mot cle (OID_TAG) et 
un entier (15), le mot cle indiquant au generateur de prendre un prefixe 
different et defini par ledit entier. 

20 9. Procede selon Tune des revendications 1 a 8, caracteris6 en ce 

que les moyens de generation comprennent en outre un generateur (54) pour 
la generation automatique d'une partie (51c) d'un integrate ur d'agents 
d'administration (51). 

10. Syst^me d'administration (10) d'une ressource informatique 

25 (11) representee par objets de finis dans une base d'informations 
d'administration (MIB) incluant un module, le systeme d'administration 
incluant au moins un processeur (14) et des moyens de memoire (15) et la 
ressource informatique incluant une architecture d'objets distribues (CORBA) 
selon un langage donne (IDL), caracterise en ce qu'il met en ceuvre au moyen 

30 d'au moins ledit processeur (14) le procede defini par l'une des revendications 
precedentes. 
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